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Abstract 

This  paper  presents  a  taxonomy  of  replay  attacks  on 
cryptographic  protocols  in  terms  of  message  origin  and 
destination.  The  taxonomy  is  independent  of  any 
method  used  to  analyze  or  prevent  such  attacks.  It 
is  also  complete  in  the  sense  that  any  replay  attack  is 
composed  entirely  of  elements  classified  by  the  taxon¬ 
omy.  The  classification  of  attacks  is  illustrated  using 
both  new  and  previously  known  attacks  on  protocols. 
The  taxonomy  is  also  used  to  discuss  the  appropriate¬ 
ness  of  particular  countermeasures  and  protocol  analysis 
methods  to  particular  kinds  of  replays. 

Introduction 

Cryptographic  protocols  employ  cryptography  to 
achieve  some  security  function.  But,  for  many  of  these 
protocols  the  structure,  hence  the  security,  of  the  em¬ 
ployed  cryptographic  algorithms  is  not  considered  to  be 
part  of  the  protocol  itself.  These  algorithms  are  gener- 
ically  represented  by  notation  capturing  only  gross  fea¬ 
tures,  e.g.,  whether  the  algorithm  is  for  public  or  shared 
keys,  whether  it  produces  a  hash  function,  etc.  Thus, 
cryptographic  algorithms  are  assumed  to  be  not  directly 
breakable  within  a  protocol.  Primary  focus  is  on  the 
possibility  of  a  penetrator  using  messages  even  when  she 
might  not  be  able  to  read  and/or  produce  them  herself. 
That  is,  most  of  the  effort  in  devising  and  reasoning 
about  cryptographic  protocols  is  directed  at  precluding 
one  form  or  another  of  replay  attack. 

Suppose  that  Ann  authorizes  a  transfer  of  funds  from 
one  account  to  another  by  encrypting  the  transfer  re¬ 
quest  with  a  signature  key  known  only  to  her.  To 
get  this  processed  she  then  sends  it  to  a  machine  that 
checks  the  signature  and  performs  the  transaction.  If  a 
penetrator1 ,  Eve,  wished  to  have  the  same  transfer  re¬ 
peated  without  Ann’s  knowing  authorization,  she  would 
not  need  to  be  able  to  produce  the  encrypted  transfer 
request  herself.  Assuming  she  can  guess  or  otherwise  de¬ 
termine  which  message  text  corresponds  to  the  transfer 
request,  she  need  only  eavesdrop  a  copy  of  the  encrypted 

1  ‘Penetrator’  is  meant  to  include  both  outside  intruders  to  a 
system  and  legitimate  principals  misusing  the  system. 


request  and  then  replay  it  at  another  time.  Something 
is  needed  to  guard  against  such  replay,  in  addition  to  a 
good  encryption  algorithm.  This  example  illustrates  a 
very  clear  form  of  replay  attack.  In  general  we  will  take 
‘replay’  to  mean  the  capture  of  a  message  or  a  piece  of  a 
message  that  is  then  used  at  a  later  time.  This  encom¬ 
passes  both  cases  where  the  original  message  is  allowed 
to  pass  unimpeded  and  cases  where  it  is  prevented  from 
arriving. 

It  is  important  to  understand  that  the  following  is  a 
taxonomy,  hence  more  than  a  list  of  replay  types  (as 
in  [Gon93]).  This  means  that  our  categorization  is  hi¬ 
erarchical  and  that  each  level  in  the  hierarchy  forms  a 
partition  of  the  preceding  level.  Thus,  the  taxonomy  is 
trivially  complete:  all  replays  (in  the  sense  just  given) 
can  be  classified  as  falling  into  one  of  the  categories  at 
each  level  of  the  hierarchy. 

The  structure  of  the  taxonomy  is  also  determined  only 
by  whence  messages  originate  and  where  messages  ar¬ 
rive.  Capabilities  of  the  penetrator  other  than  to  affect 
these  two  factors  plays  no  role  in  classification;  though 
of  course  it  may  play  a  role  in  the  possibility  of  a  given 
attack  in  a  given  category.  Similarly  the  classification 
is  independent  of  any  ability  to  detect  or  prevent  pen¬ 
etrator  actions.  This  independence  frees  us  to  consider 
which  detection,  representation,  or  prevention  mecha¬ 
nisms  are  appropriate  for  a  replay  attack  by  focusing 
on  where  it  occurs  in  the  taxonomy.  The  taxonomy  is 
surprisingly  helpful  in  this  regard  given  that  the  mod¬ 
elling  of  threats  is  so  minimal. 

1  A  Taxonomy  of  Replays 

The  full  taxonomy  can  actually  be  composed  from  two 
component  taxonomies,  one  for  message  origin  and  one 
for  destination.  We  will  first  set  out  the  origination 
taxonomy  and  explain  it.  Then  we  will  do  the  same  for 
the  destination  taxonomy. 

1.1  Origination  Taxonomy 

This  taxonomy  is  based  on  the  protocol  run  of  origin 
for  a  message  (relative  to  the  protocol  run  in  which  the 
replay  occurs).  ‘Protocol  run’  refers  to  any  single  exe¬ 
cution  of  a  protocol  by  the  relevant  principals. 


Report  Documentation  Page 

Form  Approved 

OMB  No.  0704-0188 

Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 

VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 

1.  REPORT  DATE 

1994 

2.  REPORT  TYPE 

3.  DATES  COVERED 

00-00-1994  to  00-00-1994 

4.  TITLE  AND  SUBTITLE 

5a.  CONTRACT  NUMBER 

A  Taxonomy  of  Replay  Attacks 

5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

6.  AUTHOR(S) 

5d.  PROIECT  NUMBER 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Naval  Research  Laboratory, Code  5543,4555  Overlook  Avenue, 

SW, Washington, DC, 20375 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

10.  SPONSOR/MONITOR'S  ACRONYM(S) 

11.  SPONSOR/MONITOR'S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

14.  ABSTRACT 

15.  SUBIECT  TERMS 

16.  SECURITY  CLASSIFICATION  OF: 

17.  LIMITATION  OF 
ABSTRACT 

18.  NUMBER 

OF  PAGES 

5 

19a.  NAME  OF 
RESPONSIBLE  PERSON 

a.  REPORT 

unclassified 

b.  ABSTRACT 

unclassified 

c.  THIS  PAGE 

unclassified 

Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


1.  Run  external  attacks  (replay  of  messages  from  out¬ 
side  the  current  run  of  the  protocol) 

(a)  Interleavings  (requiring  contemporaneous  pro¬ 
tocol  runs) 

(b)  Classic  replays  (runs  need  not  be  contempo¬ 
raneous) 

2.  Run  internal  attacks  (replay  of  messages  from  in¬ 
side  the  current  run  of  the  protocol) 

Wherever  we  use  ‘message’  it  is  acceptable  to  substitute 
‘message  fragment’.  In  other  words,  this  taxonomy  does 
not  distinguish  between  attacks  where  a  whole  message 
is  replayed  and  attacks  where  some  piece  of  a  message 
is  replayed.  Note  also  that  while  the  taxonomy  par¬ 
titions  replays  at  each  level,  some  attacks  might  only 
be  possible  if  more  than  one  kind  of  replay  is  involved. 
Such  attacks  might  span  more  than  one  class  of  some 
partition.  Should  this  be  confusing,  it  may  be  help¬ 
ful  to  think  of  this  as  a  taxonomy  of  attack  elements 
which  may  or  may  not  constitute  whole  attacks.  We 
now  describe  the  classes  of  attack  set  out  in  the  above 
taxonomy. 

Run  external  attacks  use  message  elements  from  one 
protocol  run  in  another.  A  classic  example  of  this  is 
the  Denning-Sacco  attack  on  the  original  Needham- 
Schroeder  key  distribution  protocol  ([DS81],  [NS78]). 
A  penetrator  who  captures  a  copy  of  the  third  mes¬ 
sage  and  has  time  to  break  the  distributed  session  key 
can  mount  an  attack.  She  can  replay  the  third  message 
later,  as  part  of  another  run  of  the  protocol.  As  a  re¬ 
sult  she  can  trick  one  principal  into  thinking  he  has  just 
authentically  exchanged  a  key  with  another.  In  reality, 
the  other  principal  is  not  there,  and  the  session  key  is 
an  old,  previously  broken  key.  This  constitutes  a  run 
external  attack  because  it  uses  a  message  from  outside 
of  the  protocol  run  in  which  the  replay  occurs. 

Run  internal  attacks  use  message  elements  from 
within  the  current  run  of  a  protocol.  An  example  of 
this  is  the  attack  on  the  initial  exchange  of  the  Neuman- 
Stubblebine  protocol  described  in  [Syv93b]  and  [Car93]. 
In  that  attack,  a  penetrator  takes  part  of  the  second 
message  and  uses  it  to  construct  the  fourth  message. 
The  attack  allows  him  to  masquerade  as  someone  else 
and  to  obtain,  or  even  to  generate,  a  session  key.  It  is  a 
run  internal  attack  because  it  uses  messages  from  inside 
a  single  run  of  a  protocol. 

Classic  Replays  are  attacks  not  requiring  contempo¬ 
raneous  runs.  We  call  these  ‘classic  replays’  because 
they  have  been  known  about  and  addressed  for  some 
time.  The  above  Denning-Sacco  attack  is  a  classic  re¬ 
play.  While  such  an  attack  uses  a  message  from  outside 
of  the  current  run  of  the  protocol,  that  message  can 
come  from  a  protocol  run  that  occurred  at  any  time 
(assuming  that  the  long  term  keys  have  not  expired). 

Interleavings  require  that  two  protocol  runs  overlap 
in  execution.2  Here  is  an  example.  The  protocol  is  one 

2  ‘Interleaving’  is  used  in  a  related  but  slightly  different  way  in 
[BGH+93], 


due  to  Burrows,  Abadi,  and  Needham.  It  is  a  variant 
they  give  of  a  draft  protocol  due  to  Yahalom,  which  they 
discuss  in  [BAN89]. 

The  BAN-Yahalom  Protocol 

(1)  A^B:  A,  Na 

(2 )  B^S:  B,Nb,{A,Na,}Kbs 

(3)  A:  Nb,{B,Kab,Na}Ka.,{A,Kab,Nb}Kb. 

(4 ) A—>B:  {A,Kab,Nb}Kbs,{Nb}Kab 

We  refer  to  the  initiator,  A,  of  the  protocol  and  the 
other  principal,  B,  as  ‘Ann’  and  ‘Bob’  respectively.  S 
is  called  the  ‘server’.  The  protocol  runs  as  follows.  Ann 
sends  to  Bob  her  own  name  (so  he  knows  who  is  at¬ 
tempting  to  communicate  with  him)  and  a  nonce,  a 
random  number  that  she  will  use  to  verify  the  fresh¬ 
ness  of  later  messages  that  contain  it.  Second,  Bob 
sends  to  the  server  his  own  nonce.  In  the  same  mes¬ 
sage  he  sends  A,  Na,  encrypted  together  with  a  key, 
Kbs,  good  only  for  communication  between  Bob  and 
the  server.  In  the  third  message,  the  server  sends  to 
Ann:  Nb,  {B ,  Kab,  Na}Kas,  {A,  Kab,  Nb}K hs  •  The  first 
encrypted  chunk  tells  Ann  that  the  server  has  been  talk¬ 
ing  to  Bob,  that  the  message  is  fresh  (via  Na),  and  gives 
her  the  session  key.  The  second  encrypted  chunk  is  for 
her  to  pass  on  to  Bob.  In  the  fourth  message,  Ann  sends 
that  chunk  to  Bob.  This  tells  him  that  the  server  has 
recently  talked  to  Ann  and  gives  him  the  session  key. 
Because  Ann  has  used  the  session  key  to  encrypt  Bob’s 
nonce,  the  second  encrypted  chunk  lets  him  know  that 
she  has  seen  the  session  key  recently.  We  now  set  out 
the  attack.  (Here  ‘Ex ’  refers  to  the  penetrator,  Eve, 
masquerading  as  principal  X .  If  this  occurs  in  the  place 
of  an  intended  recipient,  it  is  assumed  that  the  message 
is  intercepted.) 

Attack  1  on  the  BAN-Yahalom  Protocol 

(1  )A^B:  A,  Na 
(2  )B^S:  B,Nb,{A,Na}Kbs 

(T)  Ea  B:  A,(Na,Nb) 

(2 ')B^ES:  B,Nl,{A,Na,Nb}Kb. 

(3)  Omitted. 

(4)  Ea  B:  {A,  Na(=  Kab),  Nb }Kbs ,  {Nb}Kai 

This  attack  begins  with  the  penetrator  either  eavesdrop¬ 
ping  on  an  initial  message  from  Ann  to  Bob  or  sending 
it  herself.  (If  the  latter,  then  ‘A’  should  be  changed 
to  ‘Ea  at  the  appropriate  spot  above.)  After  the  sec¬ 
ond  message,  Eve  initiates  another  run  of  the  protocol 
masquerading  as  Ann.  She  uses  Na  concatenated  with 
Nb  from  the  first  run  as  the  nonce  in  step  (1')  of  the 
second  run.  Once  she  has  the  encrypted  message  she 
intercepts  from  Bob  in  (2'),  she  drops  the  second  run. 
She  then  uses  this  for  the  first  encrypted  chunk  in  the 
last  message  of  the  first  run.  Nb  was  previously  sent  as 
cleartext,  and  Kab  is  actually  Na  which  also  appeared  as 
cleartext.  Thus,  she  can  produce  the  second  encrypted 


chunk  of  message  (4).  At  the  end  of  the  attack,  Eve 
has  masqueraded  as  Ann  to  Bob  and  obtained  the  dis¬ 
tributed  session  key.  It  is  even  possible  for  her  to  have 
generated  it  herself.  The  attack  assumes  that  substitut¬ 
ing  two  concatenated  nonces  for  one  will  go  undetected 
and  be  passed  along  when  sent  to  someone  who  has  no 
need  to  check  the  nonce.  It  also  assumes  that  substi¬ 
tuting  a  random  number  generated  as  a  nonce  for  one 
generated  as  a  session  key  will  be  successful. 

This  attack  is  an  interleaving  because  it  relies  on  mes¬ 
sages  constructed  of  message  elements  from  contempo¬ 
raneous  protocol  runs.  If  the  second  run  is  not  begun 
during  the  first  run,  Eve  cannot  successfully  complete 
the  attack.  Note  that  both  classic  replays  and  interleav¬ 
ings  are  only  subcases  of  run  external  attacks.  (These 
categories  make  no  sense  for  run  internal  attacks.) 

1.2  Destination  Taxonomy 

The  above  taxonomy  is  based  on  the  protocol  run  of 
message  origin  relative  to  the  run  where  the  replay  oc¬ 
curs.  This  taxonomy  focuses  on  the  recipient  of  the 
message  relative  to  the  intended  recipient. 

1.  Deflections  (message  is  directed  to  other  than  the 
intended  recipient) 

(a)  Reflections  (message  is  sent  back  to  sender) 

(b)  Deflections  to  a  third  party 

2.  Straight  replays  (intended  principal  receives  mes¬ 
sage,  but  message  is  delayed) 

The  categories  in  the  destination  taxonomy  are  mostly 
self-explanatory.  ‘Straight  replays’  are  so  called  because 
the  message  is  sent  straight  from  the  sender  to  the  in¬ 
tended  recipient,  though  it  may  be  delayed  or  have  other 
text  appended  to  it,  generally  altering  the  significance 
of  the  message.  Attacks  using  straight  replays  are  not 
as  unusual  as  it  might  appear.  For  example,  in  the 
attack  described  in  [Syv93a]  the  penetrator  reuses  a 
message  from  Ann  to  the  server  (message  2)  as  a  dif¬ 
ferent  message  from  Ann  to  the  server  (message  4)  in 
another  round  of  the  protocol.  The  protocol  involved  in 
this  attack  was  an  artificial  example  used  for  illustra¬ 
tive  purposes.  However,  straight  replay  attacks  exist  on 
protocols  posited  for  use.  Here  is  another  attack  on  the 
BAN-Yahalom  protocol  that  involves  a  straight  replay. 

Attack  2  on  the  BAN-Yahalom  Protocol 

(1)  A  — >■  Eb:  A,  Na 

(T)  Eb  —>  A:  B,  Na 

(2')  A  —>  Es:  A,  N'a,  {B,  Na}Kas 

(2")  Ea^S:A,Na,{B,Na}Ka. 

(3 ')  S^Eb:  Na,{A,Kab,Na}Kb„ 

{B,  Kab,  Na}Kas 

(2)  Omitted. 

(3)  Es  —>■  A:  Ni,  {B,  Kab,  Na}Kas,  {A,  Kab,  Na}Kis 

(4)  A  —>■  Eb:  {A,  Kab,  Na}Khs,  {Ai}ifai, 


The  potential  damage  of  this  attack  is  not  so  immedi¬ 
ately  great  as  that  of  Attack  1.  It  only  results  in  Eve 
spoofing  Ann  into  thinking  that  she  has  exchanged  a 
key  with  Bob.  There  is  no  release  of  the  session  key. 
Nonetheless,  it  relies  on  less  assumptions  about  things 
missed  by  any  implementation,  e.g.,  substituting  nonces 
for  keys  or  doubled  nonces  for  nonces.  There  is  only  the 
rather  weak  assumption  that  Ann  will  not  detect  the 
reflection  in  the  second  run  of  her  nonce  from  the  first 
run. 

Attack  2  nicely  illustrates  all  of  the  possible  kinds  of  des¬ 
tination  replays.  There  is  the  just  mentioned  reflection. 
There  is  a  straight  replay  of  cryptotext  from  message 
(2')  in  message  (2")  of  the  second  run.  And,  there  is 
a  third  party  deflection  of  the  cryptotext  from  message 
(3')  in  message  (3). 

The  origin  and  destination  taxonomies  are  essentially 
independent  of  each  other.  Thus,  we  can  construct  the 
full  taxonomy  by  appending  either  one  to  the  finest  lev¬ 
els  of  distinction  in  the  other,  i.e. ,  by  forming  the  cross 
product  either  way.  Since  protocol  run  is  roughly  a 
broader  abstraction  than  message  recipient,  it  makes 
some  intuitive  sense  to  append  the  destination  taxon¬ 
omy  at  the  finest  level  of  origination  taxonomy.  That  is 
the  full  taxonomic  structure  we  adopt. 

1.3  Full  Taxonomy 

1.  Run  external  attacks  (replay  of  messages  from  out¬ 
side  the  current  run  of  the  protocol) 

(a)  Interleavings  (requiring  contemporaneous  pro¬ 
tocol  runs) 

i.  Deflections  (message  is  directed  to  other 
than  the  intended  recipient) 

A.  Reflections  (message  is  sent  back  to 
sender) 

B.  Deflections  to  a  third  party 

ii.  Straight  replays  (intended  principal  re¬ 
ceives  message,  but  message  is  delayed) 

(b)  Classic  replays  (runs  need  not  be  contempo¬ 
raneous) 

i.  Deflections  (message  is  directed  to  other 
than  the  intended  recipient) 

A.  Reflections  (message  is  sent  back  to 
sender) 

B.  Deflections  to  a  third  party 

ii.  Straight  replays  (intended  principal  re¬ 
ceives  message,  but  message  is  delayed) 

2.  Run  internal  attacks  (replay  of  messages  from  in¬ 
side  the  current  run  of  the  protocol) 

(a)  Deflections  (message  is  directed  to  other  than 
the  intended  recipient) 

i.  Reflections  (message  is  sent  back  to 
sender) 

ii.  Deflections  to  a  third  party 

(b)  Straight  replays  (intended  principal  receives 
message,  but  message  is  delayed) 


2  Using  the  taxonomy 

Now  that  we  have  the  taxonomy  we  take  a  brief  look  at 
some  applications  of  it. 

2.1  Looking  at  countermeasures 

This  taxonomy  is  useful  for  readily  determining  the  ef¬ 
fectiveness  of  some  replay  countermeasures  and  associ¬ 
ated  concepts.  For  example,  the  existence  of  interleav¬ 
ing  attacks  has  prompted  occasional  discussion  of  the 
inappropriateness  of  freshness  mechanisms  for  general 
prevention  of  replay.  Some  have  proposed  in  their  stead 
mechanisms  for  tying  messages  to  a  particular  protocol 
run  rather  than  to  a  particular  epoch.  Thus,  even  if  an 
interleaving  involves  only  fresh  messages,  that  the  mes¬ 
sages  are  from  different  protocol  runs  would  be  revealed 
by  such  a  mechanism.  The  possibility  of  run  internal 
attacks  shows  that  this  too  is  inappropriate  if  the  goal 
is  to  preclude  replay  in  general.  In  truth,  both  notions 
are  relevant  but  simply  not  sufficient  to  the  overall  task. 
With  respect  to  the  taxonomy,  mechanisms  addressing 
only  freshness  are  only  of  value  against  classic  replays. 
(Of  course,  they  may  be  generally  useful  for  determin¬ 
ing  message  expiration.)  Similarly,  mechanisms  local¬ 
izing  to  a  particular  run  are  only  of  value  against  run 
external  attacks. 

Another  kind  of  countermeasure  is  one  that  indicates 
who  a  message  is  from,  who  it  is  to,  or  both.  Some  ex¬ 
amples  of  these  are  discussed  in  [Mit89]  with  respect  to 
reflection  attacks  on  particular  protocols.  The  taxon¬ 
omy  delimits  the  applicability  of  these  sorts  of  counter¬ 
measures  as  well.  One  mechanism  Mitchell  discusses  is 
encrypted  from  Helds,  which  cryptographically  bind  the 
name  of  the  message  originator  to  the  message.  These 
will  work  against  reflections  but  not  against  deflections 
to  a  third  party  or  straight  replays.  Another  mechanism 
discussed  precludes  mistaking  either  sender  or  receiver 
of  a  message  via  specialized  use  of  shared  keys.  This  will 
rule  out  both  reflections  and  third  party  deflections  but 
not  straight  replays.  Some  other  related  countermea¬ 
sures  are  discussed  in  [Gon93].  As  in  [Mit89],  discussion 
is  explicitly  limited  there  to  countering  reflections. 

Both  of  those  papers  propose  introducing  asymmetry 
between  messages  X  sends  to  Y  and  those  Y  sends  to  X 
as  a  simple  means  of  countering  replay.  This  is  also  pro¬ 
posed  in  [BGH+93].  As  mentioned,  we  should  only  ex¬ 
pect  this  to  be  effective  in  the  context  of  reflections.  We 
must  also  take  care  that  format  asymmetry  is  not  itself 
attackable.  We  have  discussed  old  and  new  protocols 
above  in  which  the  attack  involves  using  a  nonce  for  a 
key.  For  example,  in  the  attack  in  [Syv93b]  and  [Car93] 
cited  above,  a  message  of  the  form  {A,  Kai,  Ti}Khs  is 
substituted  for  one  of  the  form  {A,  Na,  Ti,}xbs  ■  A  re¬ 
lated  substitution  was  made  in  Attack  1  above  on  the 
BAN-Yahalom  Protocol.  Nor  is  it  sufficient  simply  to 
vary  the  number  of  fields,  even  inside  of  a  piece  of  cryp¬ 
totext.  Attack  1  also  involved  failure  to  detect  whether 
a  plaintext  message  had  three  fields  or  two  (all  the  more 
likely  if  nonce  lengths  are  allowed  to  vary).  This  failure 
lets  a  legitimate  principal  be  tricked  into  producing  a 
three  field  cryptogram  where  he  was  to  produce  a  two 
field  cryptogram.  How  easy  it  is  to  prevent  these  sorts 


of  problems  plays  a  pivotal  role  in  how  easy  it  is  to 
introduce  effective  asymmetry  in  a  protocol  format. 

2.2  Looking  at  analysis  methods 

This  taxonomy  is  also  useful  for  determining  the  ap¬ 
propriateness  of  analysis  techniques  to  represent  and/or 
reveal  replays.  For  example,  BAN  logic,  [BAN89],  is 
clearly  directed  only  at  what  we  have  called  classic  re¬ 
plays,  the  use  of  run  external  messages  from  before  the 
current  protocol  run  began.  This  is  not  to  say  that 
a  BAN  analysis  will  never  uncover  attacks  of  another 
kind.  But,  for  example,  it  does  not  generally  handle  in¬ 
terleavings  since  freshness  will  not  reject  messages  from 
other  runs  that  were  sent  (verifiably)  after  the  beginning 
of  the  current  run.  This  is  no  criticism  of  BAN.  Rather 
it  is  an  express  demarcation  of  what  one  can  generally 
hope  to  reason  about  by  using  it. 

One  of  the  first  expansions  of  BAN  is  the  logic  GNY, 
presented  in  [GNY90].  Amongst  other  things  this  logic 
adds  means  to  assess  vulnerability  to  reflection  attacks. 
(BAN  analysis  sidesteps  reflections.  The  authors  ex¬ 
plicitly  assume  that  principals  can  recognize  their  own 
messages.)  GNY  has  notation  and  rules  to  limit  a  prin¬ 
cipal’s  inferences  regarding  a  message  to  cases  where  the 
message  originated  elsewhere.  GNY  is  thus  expressive 
enough  to  represent  at  least  some  of  both  run  inter¬ 
nal  and  run  external  reflections.  It  does  not  explicitly 
address  either  deflections  or  straight  replays.  The  anal¬ 
ysis  technique  discussed  in  [GNY90]  is  further  limited 
to  run  internal  reflections  where  the  significance  of  the 
message  does  not  change.  Thus,  according  to  the  tax¬ 
onomy,  GNY  adds  only  a  little  to  the  replay  types  de¬ 
tectable  by  BAN.  Nonetheless,  we  see  that  GNY  does 
go  beyond  classic  replays  in  dealing  logically  with  these 
concerns.  (GNY  also  addresses  other  concerns  not  cov¬ 
ered  by  BAN.) 

Other  logics  appear  to  have  more  general  replay  rep¬ 
resentation  capabilities  ( [Bie90] ,  [KG91],  [Syv93a]),  as 
do  other  protocol  analysis  methods  ([MCF87],  [SM93], 
[BGH+93]).  Some  of  these  appear  capable  of  repre¬ 
senting  replays  of  all  kinds.  However,  detection  is  an¬ 
other  matter.  To  date  only  the  NRL  protocol  analyzer 
([Mea91],  [Mea92])  appears  to  be  generally  capable  of 
detecting  all  types  of  replays.  It  is  hoped  that  the  above 
taxonomy  will  aid  in  the  development  of  new  and  exist¬ 
ing  techniques  for  addressing  replay  attacks. 
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